1. Field of the Invention
The present invention relates to an image forming apparatus, control method, and program, which control peripherals using applications and, more particularly, to an image forming apparatus in which a plurality of applications control peripherals using a common device driver.
2. Description of the Related Art
A multi-functional peripheral equipment (MFP) has various functions. As one of these functions, a mechanism that allows the user to install favorite applications after he or she purchased the MFP is available. This mechanism is normally used for the purpose of customizing functions of the MFP in correspondence with a user's environment. These applications often use functions of externally connected devices such as USB devices. In this case, some types of device drivers used to control the behaviors of the USB devices are required. The types of device drivers will be described below. However, note that terms to be described below are not widely known.
One type of device driver is a generic standard device class driver. Note that “class” indicates a category grouped depending on functions provided by USB devices. The general-purpose class indicates a class except for a vendor-specific class (to be described later) of those classes. The generic standard device class driver is a device driver, which is used to control the behaviors of a USB device which belongs to the general-purpose class. Due to existence of this generic standard device class driver, vendors who develop USB devices can enhance the developing efficiency of device drivers. By contrast, when each vendor wants to provide a function which is not defined in the compatible general-purpose class, it has to uniquely develop a device driver which provides that function. As a practical example of the generic standard device class driver, an HID class driver, Mass Storage class driver, and the like are available. In general, an OS such as Windows® or Linux provides such generic standard device class driver.
Another type of device driver is a vendor specific class driver. Vendors indicate developers who develop USB devices. A vendor specific class driver is a dedicated device driver, which is uniquely developed by a vendor, so as to control the behavior of a USB device which does not belong to the aforementioned general-purpose class. The vendor specific class driver can freely define behaviors for functions provided by the vendor. However, when the OS version has changed, a device driver has to be created again accordingly.
The final type of device driver is a common device driver. The common device driver is a concept which does not exist in a general OS such as Windows® or Linux, and allows the aforementioned application to freely control the behaviors of USB devices. Unlike the aforementioned vendor specific class driver, not a device driver but the application has a logic of controlling the behaviors of USB devices. Although the performance of the common device driver is inferior to the vendor specific class driver, that driver can have scalability independently of the OS version.
A simple sequence upon selecting an appropriate device driver from these types of device drivers will be described below. Note that selecting a device driver in correspondence with a certain USB device and letting that driver control the USB driver is expressed by “loading a device driver”. When a certain USB device is connected to an information apparatus, an OS searches for an appropriate device driver. Each generic standard device class driver and vendor specific class driver register identifiers required to identify USB devices supported by themselves in an OS. Therefore, the OS selects a driver corresponding to the identifier of the connected device, and loads the selected driver. By contrast, since a common device driver cannot specify a device supported by itself, it does not register any information in the OS. Upon detection of connection of a USB device, the OS checks if a compatible device driver is available in the order of vendor specific class drivers and generic standard device class drivers.
Windows® as a representative of a general OS does not incorporate any common device drivers. For this reason, Windows® has a specification for displaying, when a compatible device driver cannot be found from registered generic standard device class drivers or vendor specific class drivers, a wizard dialog for prompting the user to install a new appropriate driver. Likewise, since Linux does not incorporate any common device drivers, no device driver is selected when a compatible device driver cannot be found from registered generic standard device class drivers or vendor specific class drivers.
As an example of a platform that includes common device drivers, an MFP-dedicated application platform which is implemented using Java® is known. In this platform, when a device driver compatible with an installed device cannot be found, a common device driver is loaded.
As a related art about device driver selection, Japanese Patent Laid-Open No. 10-27149 is available. Japanese Patent Laid-Open No. 10-27149 comprises a dispatch device driver which has device driver registration information that describes the relationship between device drivers and device identifiers, and selects a device driver compatible with a device in accordance with this information. According to Japanese Patent Laid-Open No. 10-27149, addition of a new driver and a change of the relationship in the device driver registration information can be made.
In some cases, an application which controls a USB device via the aforementioned common device driver wants to execute special control with respect to a general-purpose class device. For example, a practical example of such case is the following demand. That is, when a given application wants to use, as an authentication device, a magnetic card reader installed as an HID class, it wants to prevent from notifying other applications of the communication contents. As another example, a special encryption area is demanded to be assured in a memory device installed as a Mass Storage class. In order to meet such demands, it is possible to install a new vendor specific class driver. However, installation of the vendor specific class driver has high dependence on the kernel of an OS and poor portability. Since the vendor specific class driver runs in a kernel mode, providing unit that allows replacing the driver possesses the risk of a security level drop upon using an apparatus. For this reason, use of the vendor specific class driver cannot often be a solution in practice.
In order to meet the above demands, it is desirable to select and use a common device driver. However, according to the aforementioned device driver selection logic, when a generic standard device class driver which has a higher priority than a common device driver is registered as a driver compatible with a newly installed device, that driver is preferentially selected and loaded. Hence, an application cannot control that device. As a simple method of solving such problem, a method of preparing a switch that disables generic standard device class drivers may be used. However, when this method is used, other general-purpose class USB devices can no longer be used. Hence, this method is not a desirable solution.
As another solution, common device drivers may be registered as vendor specific class drivers. However, since information of a USB device to be controlled by an application cannot be detected from a common device driver, the common device driver cannot register an identifier required to identify the USB device supported by itself in an OS. Furthermore, in the Linux OS, as its specification, there is a restriction that one device driver cannot be registered in the OS to have two or more different priorities. For this reason, when a common device driver is registered as a vendor specific class driver, registration for selecting a common device driver cannot be made for other USB devices for which no compatible device drivers are registered. As a result, other applications cannot control USB devices.
As described above, a demand has arisen for a mechanism that allows an application, which controls a USB device via a common device driver, to preferentially select a common device driver in consideration of a case in which such application wants to execute special control with respect to a general-purpose class device.